fix(arborist): recognize registry-mediated tarballs - #9921

Summary

• recognize registry-mediated tarballs served from same-origin sibling paths without trusting arbitrary lockfile URLs
• preserve alias target identity and scoped authentication for ordinary peers, root-selected aliases shared with ordinary dependencies, and linked installs
• validate locked versions and use cache-first registry evidence with coalesced abbreviated metadata requests
• keep requested signature/attestation verification separate from URL-only evidence
• document cold-cache and offline requirements

Problem

During reification, Arborist passes registry tarballs to pacote as name@URL. npm-package-arg parses that temporary spec as a remote dependency, so Arborist needs a narrow exemption for registry-mediated tarballs.

The existing classifier only recognized tarball paths beneath the configured registry path. Private registries can legitimately advertise tarballs from another path on the same origin. It also selected registries using the installed dependency slot: for hoek: npm:@npm/hoek@6.1.4, that loses the target scope and can select the wrong registry or credentials. Both cases can incorrectly fail with EALLOWREMOTE under the npm 12 default allow-remote=none.

Implementation

Package identity and compatibility

Identity comes from valid dependency specifications, not package/lockfile name fields. Aliases are unwrapped to target names. Ordinary peers constrain the installed slot rather than redefining an alias target. Project/workspace selections also take precedence over ordinary compatible transitive requirements, while disagreeing explicit alias targets remain rejected. A transitive alias cannot supersede a plain root selection.

Linked installs carry this identity through intermediate proxies and synthetic store nodes. Extraction uses the target identity independently of remote-permission mode, so authentication follows the target scope while the install location remains the alias slot.

Sibling-path verification

The configured-registry-path fast path remains. A same-origin URL outside that path is permitted only when registry evidence for the trusted package and exact version advertises the same effective tarball URL.

Locked versions must be exact semantic versions; aliases, ranges, tags, URLs, and other dependency specifications in that field cannot redirect verification. Metadata names and versions must match. Host replacement is applied consistently to both URLs. Fragments are ignored; the remaining URL, including path and query, must match.

Metadata reuse and request behavior

• Capture compact URL evidence from actual pacote manifest responses during resolution, never from serialized node/lockfile fields.
• Reuse full or abbreviated packuments already present in the memory cache.
• Request abbreviated metadata on a verification cache miss and inspect the exact version entry without treating the locked version as a dependency spec.
• Share pending verification requests per registry/package across instances and versions. Retain compact URL evidence even when the production cache discards large responses or responses without Content-Length.
• Keep offline requests offline. An abbreviated ENOTCACHED result permits an offline lookup of the full HTTP variant, accounting for Vary: Accept.
• Treat captured evidence as URL-only regardless of verification flags during resolution. Explicit signature/attestation verification still uses the dedicated full-metadata path; abbreviated old-lock hydration cannot bypass it.

Cold locked sibling-path installs can still require metadata requests. A cached tarball alone does not establish the additional evidence needed for an offline sibling-path install. This is an intentional availability/performance tradeoff, not a promise of zero additional requests.

Policy boundaries

Already-permitted implicit/explicit all, and root-direct requests under root, skip URL verification. Metadata failures, mismatches, unverifiable identities, and cross-origin URLs do not grant an exemption. Explicit remote dependencies remain governed by the configured policy. Extraction continues to receive the locked integrity value.

Regression coverage

• malformed locked-version specs, including an alias injected into a wildcard lockfile entry, without unauthorized metadata or tarball requests
• exact metadata name/version/URL matching, query mismatches, missing versions, and preserved semver build metadata
• full/abbreviated memory caches, real offline HTTP variants, tarball-only caches, concurrent versions, and production-cache eviction conditions
• alias credentials across permission modes; ordinary/optional peers; root-selected aliases with ordinary consumers; hoisted/linked installs; conflicting explicit selections
• effective alias overrides, accepted version ranges, and both linked-node transformations
• old-lock abbreviated metadata missing an attestation pointer present in full metadata, ensuring requested verification still runs and fails closed
• npm ci tampered-lockfile regressions and updated configuration documentation

Fixes #9796